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REMARKS 

Claims 1 to 6, 8 to 10, 19 to 24, and 26 to 28 are pending in this application, of which 
claims 1 and 19 are the independent claims. 1 Favorable reconsideration and further examination 
are respectfully requested. 

Initially, the method claims were rejected under §101 for allegedly not being directed to 
statutory subject matter. As shown above, the method claims now recite that they are performed 
on a processing device. Furthermore, independent claim 1 recites 

changing the operative version in connection with changes to the simulation version, the 
operative version comprising third objects that are versions of the first objects that are changed in 
accordance with the second objects. 

Thus, the method claims are (1) tied to a statutory class, and (2) transform underlying subject 
matter, namely changing objects, i.e., "third objects that are versions of the first objects that are 
changed in accordance with the second objects". Accordingly, withdrawal of the §101 rejection 
is respectfully requested. 

Independent claim 1 was rejected as follows: 

Claims 1-15 and 19-33 are rejected under 35 U.S.C 103(a) as being unpatentable 
over "Microsoft Project 98 Support Course" ("MSP 199$**) In view of "Microsoft Project 
2002: Training Courseware, Lesson 19: Earned Value" ("Chapter 19") and "Microsoft 

Project 2002: Training Courseware, Lesson 20: Multiple Projects* ("Chapter 20"), and 
further in view of Basford, "Earned Value Reporting for the Department of Energy * 2 



1 The Examiner is urged to independently confirm this recitation of the pending claims. 

2 Office Action, pages 3 and 4 
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Independent claim 1 is shown below: 



1. A method performed on a processing device, comprising: 

storing a simulation version of a project baseline, the simulation version comprising first 
objects that define elements of the project baseline; 

copying the simulation version to create an operative version of the project baseline; 

changing the simulation version by associating second objects with the baseline objects, the 
first objects being separate from the second objects and the first objects not changing when the 
simulation version is changed; 

changing the operative version in connection with changes to the simulation version, the 
operative version comprising third objects that are versions of the first objects that are changed in 
accordance with the second objects ; 

updating a portion of the project baseline that succeeds a time at which the operative version 
is changed; and 

obtaining, via the changed operative version, an earned value for a project that corresponds to 
the updated project baseline. 



The applied art is not understood to disclose or to suggest at least the features of claim 1 that are 
underlined above. In this regard, the MSP 1998 reference explains how Microsoft Project 98 
incorporates the earned value concept into its system. MSP 1998, however, is written from the 
perspective of a user and does not address how its underlying data (e.g., objects) is stored and 
changed. Basford is written to explain the earned value concept for the department of energy. 
Basford likewise does not address how data associated with its process is stored and changed. 
Chapters 19 and 20, which relate to a Microsoft Project 2002 training course, are also written 
from the perspective of user and, therefore, suffer from deficiencies similar to the foregoing 
deficiencies of MSP 1998 and Basford. We note that, in Chapter 20, page 12 indicates that 
drawing objects are stored, and page 13 describes cross-project links. However, these features 
are not understood to render the foregoing features obvious. 
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Prior claims 5 to 7 were directed to, among other things, keeping a task added to a 
simulation version separate from previously-existing tasks, and to incorporating the task into an 
operative version. These claims were rejected as follows: 

Claim 5 : MSP 1998 discloses: augmenting the simulation version with a task; mapping 
the task to the operative version; and reformulating the operative version to account for the task 
prior to obtaining the earned value (sec page 6-33; also note that Microsoft Project allows users 
to add lasks^projeets and recalculate earned values), 

Claim 6 : MSP 1998 discloses wherein augmenting comprises adding the task to the 
simulation version but keeping the task separate from previously-existing tasks on the simulation 
version (sec page W3; see also page 1 3 of Chapter 20). 

Claim 7 : MSP 1998 discloses wherein reformulating the operative version comprises 
incorporating the task imo the operative version so iliat the project baseline is changed lo 
accommodate the task (sec page 6-33). 3 



The cited portions of MSP 1998 and chapter 20 are not understood to disclose or to suggest the 
foregoing features of claim 20. Page 6-33 of MSP 1998 recites: 



3 Office Action, page 6 
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Earned Value from Inserted Projects 

When an Inserted Project is opened or dosed, updated total earned values fietds from the Inserted 
Project are stored in the parent project. 

The behavior of timephased earned value fields for an Inserted Project depends on whether it is 
open or closed. 

• If an Inserted Project is closed in the parent project, then the Inserted Project does not display 
any timephased earned value data. 

When you save a baseline in the parent project, the Inserted Project's total BCWS, and BCWP 
values are saved too. If there are any assignments on the Inserted Project task in the parent 
project, the assignment canned value data is saved, but assignment timephased earned value 
data is not displayed. 

If you have not saved a baseline on the parent project, then BCWS, Baseline Cost and BCWP 
for the Inserted Project task are all 0 and cannot be displayed. Also, SV is 2ero, and CV - 
negative of ACWP, since CV « BCWP - ACWP - 0 - ACWP = - ACWP. 

The Inserted Projects ACWP value is saved with the parent project, without having to save a 
baseline in the parent project. That's because ACWP docs not depend on baseline values. 

When an Inserted Project is open in the parent project, then it can get and display timephased 
earned value data. The earned value data coming from the Inserted Project uses the Inserted 
Project's Status date, not the parent project's status date. 

While it is true that MSP 1998 allows a user to insert a project into a parent project, it says 
nothing whatsoever about objects for both projects, much anything approximating: 

changing the simulation version by associating second objects with the baseline objects, the 
first objects being separate from the second objects and the first objects not changing when the 
simulation version is changed; and 

changing the operative version in connection with changes to the simulation version, the 
operative version comprising third objects that are versions of the first objects that are changed in 
accordance with the second objects. 



Page 13 of Chapter 20 describes an ability of a user to link tasks from one project to tasks in 
another project. We do not understand it to address changing simulation and operative versions 
in the manner claimed above. The text from page 13 is reproduced below. Should the Examiner 
disagree, the Examiner is respectfully requested to point out where the foregoing features are 
disclosed or suggested by that text (either alone or in combination with other art). 
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Cross-Project Links 

Cross-project linking enables the user to link tasks in one project to tasks in another project. 

Microsoft Project supports true cross-project linking. The user can include a path and filename in the 
Predecessor and Successor fields, followed by a slash and the usual relationship syntax. 

For example, if C:\MyFRes\P1 ,mpp\24FS+3d Is entered in the Predecessor field, then the 
predecessor has ID 24 in the file C:\MyRJes\P1 .mpp, and the relationship is Fintsh-to-Start with 3 
days of lag. 



Cross-Project Linking Terminology 

The term internal is used to describe those tasks that exist in a project. External relates to those tasks 
outside of a project Use of either of these terms depends on the specific project in question. To avoid 
confusion, this discussion assumes the active project is the internal project unless stated otherwise. 

When an external link is created in the active project, replicated tasks are created in both the external 
and active projects. 

The term ghost task is used to refer to an external (replicated) task, however, an external task is not 
displayed with the ghost task formatting in the active project if the parent of the externa! task has 
been inserted into the active project. 

One project gets an external successor task and the other gets an external predecessor task. When 
either project is displayed alone (for example, does not contain the other as an Inserted project), the . 
external task Is displayed with special light gray ghost formatting so it can be easily distinguished 
from other tasks. 

If an external task is displayed as a ghost task in the active project it gets its own ID in the active 
project (not necessarily the same ID it has in its parent project). A predecessor ghost task is inserted 
just before the corresponding internal successor task, and a successor ghost task is inserted just 
after the corresponding intemai predecessor task. However, if a ghost task representing the external 
task already exists, then that ghost task is used to represent the external task in ail the relationships it 
may have with tasks in the active project. In other words, if two tasks in the active project both have 
the same external predecessor, there is only one ghost task representing that external task in the 
active project 



For at least the foregoing reasons, we believe that claim 1 is patentable over the applied art. 
Independent claim 19 is a machine-readable medium claim that roughly corresponds to claim 1, 
and is also believed to be patentable. 

Dependent claims are also believed to define patentable features. Each dependent claim 
partakes of the novelty of its corresponding independent claim and, as such, has not been 



discussed specifically herein. 
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It is believed that all of the pending claims have been addressed. However, the absence 
of a reply to a specific rejection, issue or comment does not signify agreement with or 
concession of that rejection, issue or comment. In addition, because the arguments made above 
may not be exhaustive, there may be reasons for patentability of any or all pending claims (or 
other claims) that have not been expressed. Finally, nothing in this paper should be construed as 
an intent to concede any issue with regard to any claim, except as specifically stated in this 
paper, and the amendment of any claim does not necessarily signify concession of 
unpatentability of the claim prior to its amendment. 

In view of the foregoing amendments and remarks, we respectfully submit that the 
application is in condition for allowance, and such action is respectfully requested at the 
Examiner's earliest convenience. 

The undersigned attorney can be reached at the address shown below. All telephone calls 
should be directed to the undersigned at 617-521-7896. 

Please apply any other required fees to deposit account 06-1050, referencing the attorney 
docket number shown above. 

Respectfully submitted, 

July 27, 2009 /Paul Pysher/ 

Date: 

Paul A. Pysher 
Reg. No. 40,780 

Fish & Richardson P.C. 
225 Franklin Street 
Boston, MA 02110 
Telephone: (617)542-5070 
Facsimile: (877)769-7945 



